home *** CD-ROM | disk | FTP | other *** search
- SoftBoot Documentation
-
- Last Updated 11/09/92 for SoftBoot 3.31
-
- INTRODUCTION
-
- Well, you've just bought that 68040 card for your A3000 or just thought
- putting ROMs in your A3000 was a good idea. Commodore has begun to ship A3000s
- with 2.04 (or later) Roms built-in. You've lost your SuperKickstart feature,
- haven't you? This means that you can't run, in a recoverable fashon, new Beta
- versions of the A3000 AmigaDos Operating System or can't even run measley old
- 1.3. Until Now. Introducing 'SoftBoot', the new SuperKickstart Emulator for the
- A3000. Supporting the 68040 and the built-in 68030 CPU of the A3000, you can
- now run any version of the operating system (including 1.3!) in a completely
- reboot-survivable way. Many hundreds of hours and many hundreds of power cycles
- on my poor old A3000 have resulted in a near bullet-proof implementation. The
- process of reboot recovery is clean and unobtrusive to the new OS. There is no
- old OS aftertaste, so to speak. Cold|Cool|WarmCapture are not used. Program
- failure will result only if the ROM image, ExecBase structure, MMU tables,
- or reboot recovery routines are corrupted by an errant program.
-
- What do you need to run SoftBoot? Besides this very powerful program, you
- need SuperKickstart files. SoftBoot will load the devs:Kickstart file
- for 2.04+ versions of AmigaDos (including 3.0), or it can load the
- Devs:Kickstart1.3 file for AmigaDos 1.3. Note these must be the SuperKickstart
- versions with attached 'bonus' areas. Some interesting variations will be
- discussed later on.
-
- You must use OldFileSystem or FastFileSystem for your system paritions. I
- highly recommend creating a System2.0: partition and a System3.0: partition
- and using HDToolBox to enable the one you wish to boot from. If you create a
- unique filesystem partition, like MS_DOS or DCFileSystem partitions, PLEASE:
- MAKE SURE THAT THE FILESYSTEM IS LOADED INTO THE RIGID DISK BLOCK (RDB)!!!!!
-
- Failure to do so may render the data unreadable under 2.04 and who knows what
- damage may occur. Softboot is not responsible for any damage if that occurs. In
- general, this software is provided as-is and the user accepts all risks in
- using it.
-
- SoftBoot V3.31 and later
-
- There are a number of powerful operations possible with SoftBoot. Some
- which work on other machines besides the A3000. For example, the SOFTBOOT
- parameter performs a soft reset of any Amiga. If you try to use a
- feature of SoftBoot that your Amiga does not support, it will (usually)
- tell you. If you invoke SoftBoot with the '?' parameter, you will get
- the following text printed on your Shell:
-
- SoftBoot V3.31 [NOCACHEZ2][KILLROM][NOCATCHROM][ONETHREE]
- [BOTH][SOFTBOOT][NOBUSERRORS][FASTROM]
- [ENTTX][OVRMMU][NOCACHEZ3][Z3ALL]
-
- Each of the parameters will be discussed next:
-
- FASTROM
-
- The FASTROM parameter causes the current motherboard ROM to be copied into
- fast RAM and remapped with the MMU. While you can do this with a 68030 and
- the 'CPU' program, SoftBoot works with both 68030 and 68040 systems. It
- will even accomodate non-A3000 68020/68851 systems! The FASTROM setup will
- die on any hardware reset (Ctrl-LAmiga-RAmiga).
-
- KILLROM
-
- To kill any MMUed ROM setup and reboot the machine, use the KILLROM parameter.
- Note that it takes effect with no time delay. Make sure all files are closed
- and that there is time for the final write to occur before performing this
- command. KILLROM wipes out RAD:, too.
-
- SOFTBOOT
-
- The SOFTBOOT Parameter will work with any Amiga. It simply performs a
- system friendly reboot. It also takes effect immediately. The SOFTBOOT
- parameter is to be used primarily for forcing a MMUed OS to load a floppy
- disk-based game or program without going through the reboot recovery
- procedure. This guarantees that you will get the purest OS that money
- can buy! The same warning in KILLROM applies here: Make sure all files are
- closed and there is time for the final write to occur before executing
- the SOFTBOOT parameter.
-
- This routine simply calls the ColdReboot() function. Avoid making 3.0 EPROMS
- and running SoftBoot's FASTROM option. This option just temporarily allocates
- the memory for the ROM and MMU tables. If the MMU is on, then upon reboot,
- that same memory will be up for grabs and will likely be stomped on by some
- application program, corrupting the system.
-
- By the same token, it is OK to FASTROM a softloaded OS, although the
- reasoning for doing so is questionable. ColdReboot() is SetFunction()ed when
- a softloaded OS is made, so any foreign MMU environment will be converted
- back to the protected MMU environment prior to system reset.
-
- OVRMMU
-
- The default operation of SoftBoot is to check to see if the MMU is in
- use and print a warning message and quit if it is in use. Because
- 68040.library may build a MMU table, you may want to force SoftBoot to
- kill a foreign MMU setup. To do so, use the OVRMMU option. The SoftBoot
- options which do not result in a system reset are written as carefully
- as possible to build a new MMU setup and switch over without crashing
- the machine. Using the OVRMMU option, you can run multiple FASTROMs
- until you fragment/run out of memory.
-
- Note that with Softboot3.31, you can change Dev:kickstart files and
- load another MMU setup over a previously existing softloaded rom. The
- safer and more recommended way is to copy the kickstart file and
- issue a SoftBoot KILLROM command and have your startup-sequence SoftBoot
- command reload the new OS file.
-
- ONETHREE
-
- The most difficult mode to support: ONETHREE forces SoftBoot to load the
- Devs:Kickstart1.3 file instead of the 2.0 or 3.0 SuperKickstart. Certain
- things need to be known before using this parameter: 1) Reboot recovery is
- via ColdCapture() for this option only. Any program which obliterates
- ColdCapture() will cause the motherboard ROM OS to be reloaded on the
- next hardware reset. 2) All disk partitions will be visible; this
- means that 1.3 will probably try to boot from your 2.0 partition. I
- didn't want to monkey with your Rigid Disk Blocks, so you need to do
- one of two things: You can use HDToolBox to increase the Boot Priority
- of your 1.3 partition before running 1.3, or you can make a boot floppy
- which performs the assigns to your 1.3 partition and then jump to its
- startup-sequence. If you choose the former, you must hold down both
- mouse buttons when rebooting back to 2.0 so you can select the 2.0
- partition to boot from.
-
- The 68040 doesn't like the Bonus code real well. Kickstart 1.3 will only load
- off a hard disk drive if it is the first partition on the drive and
- needs to be the highest SCSI address, with six being preferable. If you
- forget to change with HDTOOLBOX, a repeatable guru may be possible in 040
- mode. Stick any bootable floppy into the drive to stop it. The drives
- are accessable, and softboot can be directly addressed from the CLI.
-
- However, it may just be easiest to boot from a 1.3 Workbench floppy disk.
- By the way, ZorroIII is not supported in 1.3. Other than that, it works
- just fine folks! Really! Remember the 68040 and 1.3 barely work together.
- The 68030 and 1.3 work pretty OK: Crashes are pretty frequent. Be forewarned
- and forearmed!
-
- All partitions must have the filesystem loaded in the rigid disk block!
- The stability of other than OFS and FFS partitions cannot be guranteed under
- OS 1.3! Personally, I only would use 1.3 for floppies and try not to use the
- hard disk at all. However, I have a lot of CDTV discs which only play under
- 1.3, so I will occationally use a special partition I've set up.
-
- AmigaDos 2.0 AND ON
-
- Actually invoking SoftBoot with no parameters or any of the remaining
- ones not yet discussed will load the Devs:Kickstart file for an alternate
- operating system. The following describes what these parameters are and how,
- why and when to use them:
-
- BOTH
-
- One of the really interesting features of SoftBoot is that it works
- with both the 68030 and 68040 processors. If you invoke the BOTH parameter,
- MMU tables will be built to support both the 68040 and the 68030. There
- really isn't much of an overhead as the 030 MMU tables require only
- 32K bytes of additional RAM. The 68040 can be a bit better or quite a bit
- worse. The 68040 MMU tables require 9K for the basic A3000 motherboard.
- That's not too bad! However, if you have a Zorro III card, SoftBoot must
- build additional MMU tables to the tune of 66K bytes per 256 megabyte
- segment. This memory is all dynamically allocated as required.
-
- The great thing about the BOTH parameter is when you have a 68040 card that
- can be switched back and forth to/from the 68030: If your switch program
- works, you can stay in the same RAM-based OS without having to go
- through the motherboard ROM! (OK for just a few milliseconds! Truth in
- advertising, you know!).
-
- If you don't invoke the BOTH parameter, then MMU tables will be built for
- whichever CPU is currently in operation. The question naturally arises:
- What if I switch CPUs? Heaven forbid, disaster surely won't come will
- it? No. The RAM formerly used for the ROM and MMU tables are always allocated.
- You will see a 532K (approx) loss of ram, but will be running on the
- motherboard ROM. Switch back to the other CPU and the Ram-based OS will
- again take effect! Neat Huh! If you want all your RAM back, use the
- SoftBoot KILLROM option. You will lose everything in both modes then.
-
- So, in conclusion, You can have one CPU running a RAM-based OS, the
- other, or both running RAM-based. Or be a spoil sport and run
- neither.
-
- Note that with the Workbench V39.26 and later (Commodore's) 68040.library,
- Progressive Peripherals 68040s will become unable to switch modes. You can
- fix this by running a 'SoftBoot FASTROM OVRMMU'. SoftBoot's default setup will
- then allow the PPS Switch program to work. Since you are rebooting to change
- processors, the loss of 600K for the FASTROM will be temporary.
-
- ENTTX
-
- The MMU tables that 68040.library builds all assume ZorroIII I/O cards
- are present. One of the things it does is turn the transparent translation
- registers off. Theoretically there is a performance hit, as it only
- takes one clock cycle to pass through the transparent translation registers
- and three memory cycles to obtain a translation if the MMU page translation
- is not stored in the 68040 address translation cache. At first glance, there
- should be a major performance hit. Apparently Motorola did a wonderful
- job in the ATC design as it stays there over 90 percent of the time,
- minimizing the perfomance loss to about 2 percent. If you do not have
- Zorro III I/O, using the ENTTX option turns on the transparent
- translation registers, giving back some speed. The down side is that this
- may affect how reads/writes to non-existant memory areas are handled in the
- A3000. 68040.library's MMU tables will catch all accesses to non-existant
- RAM without going through the jerky 350 msec hardware bus timeout. You will
- lose this, in some memory areas, without using the NOBUSERRORS option,
- discussed elsewhere.
-
- NOCACHEZ2
-
- If a Bridgeboard is detected, the ZorroII space will be automatically declared
- non-cacheable. Otherwise, it is fully data and instruction cacheable
- (No parameter required!). If you have any other I/O device that winds up in
- the area reserved for Zorro II RAM (0x00200000-0x009fffff), then you need the
- NOCACHEZ2 option. Note this also works for the 68040/1.3 mode. The 68030/1.3
- MMU setup is defined in the 'Bonus' section of the Devs:Kickstart1.3 file and
- is not alterable.
-
- NOCACHEZ3
-
- The default behavior of SoftBoot is to cache all Zorro III space. If you
- have a ZorroIII I/O card, you may need to use the NOCACHEZ3 option. This
- option causes both the MMU tables and the transparent translation registers
- to be be declared as non-cachable. Note that this parameter has an affect
- when creating a softloaded operating system and also when the ENTTX option
- is invoked. In the latter case, the data transparent translation regisers
- are declared serialized noncachable. If you are running the newer
- 68040.library, it will make the proper I/O sections non-cachable, and
- leave Zorro III RAM at nearly full speed.
-
- Z3ALL
-
- There has been some talk about possible changes in the location of ZorroIII
- autoconfiguration addresses to suit the 68040's tranparent translation
- registers. When you run SoftBoot, it assumes the memory map is going to
- remain the same from one OS to the next. There is no way to figure out where
- the next OS might place a Zorro III board until it has gone through the
- autoconfiguration process, in which case it is too late for SoftBoot to
- build MMU tables. The only solution is to use the Z3ALL parameter until you
- can get new ROMS/EPROMS in your A3000 which reflect the new memory
- mapping. The Z3ALL parameter builds MMU tables for ALL of Zorro III space.
- This is very expensive and requires over a megabyte of additional RAM.
- This is the only way to make ZorroIII work if the memory map does change.
- That way, there will be valid MMU tables no matter where the OS decides to
- put a board. Note that the Z3ALL parameter is a NOP if there isn't a Zorro III
- card in your machine.
-
- NOBUSERRORS
-
- When I first got my 040, I was disgusted at the number of applications
- which die with an 80000004 or 80000003 Guru. Through some careful sleuthing,
- I discovered that these were caused by the A3000 Bus Error control hardware.
- I also discovered that the 040 was very difficult to recover from a bus error
- as an RTE command just reruns the cycle. Not good unless you remap RAM
- to all of the memory space (68040.library does something just like that). Even
- better is that all 2.0 Kickstarts to date assume an 030 Stack frame in the
- Bus Error exception handler. Apparently the 030 can fiddle with the stack and
- 'fake' the access. With an 040, this 'Twiddling' causes the aforementioned
- Gurus. At least it winds up in a mode that brings up a requester from which
- you can terminate the task or reboot. The motherboard Bus Error generation
- hardware responds whenever an access is made to an address in the machine
- which doesn't physically exist. This will happen on a read or a write. Yucch!
- Since the ROM just ignores the cycle for the 68030, why even activate the
- bus error hardware? Even worse, the hardware bus cycle takes 350 milliseconds
- to generate. That is why you get those funky and jerky mouse pointers
- when accesses to non-existant memory occurs.
-
- Fortunately, there is a solution. Turn off the Bus Error generation hardware.
- The NOBUSERROR parameter will perform this magic for you, enabling all
- those programs which run on 68040s on the A2000 and don't on the stock-
- programmed A3000 motherboard to have a chance at working. No guarantees!
-
- Any program which accesses RAM outside of its own space is broke. Many
- programs do not hurt as they only _READ_ these locations. As far as
- writes goes, well there isn't RAM there anyway. But it is indicative of
- a sick program. As a result, the default behavior is to let bus errors
- crash a task. Use of the NOBUSERROR parameter is at your own risk.
- Note that the NOBUSERROR parameter is a NOP when the 68030 or 1.3 is in
- use.
-
- NOCATCHROM
-
- The NOCATCHROM parameter enables a custom error trapping handler to
- be installed in the Bus Error exception vector. This handler only
- catches and corrects writes to ROM space or areas declared invalid in
- the MMU tables. A real genuine BUS error or any other type of exception
- which generates a 68040 access error besides an invalid access or an illegal
- write will be forwarded to the ROM Guru-handler. This is the default
- operation of SoftBoot. If the NOCATCHROM parameter is involked, SoftBoot
- is prevented from patching the vector. Again, this command is a NOP
- under 1.3 or the 68030 processor.
-
- TRICKS AND TIPS
-
- 1) Now that you've fallen in love with some future OS, and are very tired
- at having to open a CLI/Shell and run SoftBoot manually - have I got a
- trick for you! If you put SoftBoot in the Startup-Sequence, just ahead of
- SetPatch, you will get a power-on SuperKickstart-like effect. The
- Workbench screen does not normally open until IPrefs is run. The screen
- stays white (3.0+ is black). When SoftBoot is loaded via the Startup-Sequence,
- it will load your favorite version of the OS and reboot. You will see a second
- dark grey/light grey/white sequence, but you will not see the
- Workbench screen until you are softloaded. The second time through,
- SoftBoot will detect the MMU is in operation and abort with no operation,
- allowing the startup-sequence to continue! The following is the
- suggested use for AmigaDos 2.0 and 3.0:
-
- SoftBoot > nil: [OPTIONS]
- SetPatch > nil:
- SoftBoot > nil: ENTTX [OPTIONS]
-
-
- Note: BOTH is a recommended option if you can switch CPUs and want to always
- stay in the same OS.
-
- The second SoftBoot command (ENTTX) is to reenable the transparent translation
- registers. This is optional. The only parameter for SoftBoot ENTTX is NOCACHEZ3.
-
- Note: When installing a new Workbench via the Installer, do not let it
- automatically reboot the machine when it is finished. Exit and edit the new
- s:startup-sequence to reflect the SoftBoot command lines. If there is a
- new kickstart file, copy it to devs:. Then reboot the machine into the
- new OS via the SoftBoot KILLROM parameter.
-
- HOW TO MAKE A 1.3 OR 2.0 OR LATER KICKSTART
-
- As a developer, you can obtain a new superkickstart image from CBM or
- via closed listing sections on BIX. UnLharc the file and copy it to
- the devs: directory to a file called Kickstart.
-
- If you have a SuperKickstart Disk, on your 2.0 A3000 install disk is a script
- file called Update2.0x. This script will create an A3000 kickstart from your
- Superkickstart disk as Devs:Kickstart. For 1.3, you need the A3000 1.3
- SuperKickstart Disk and use the following command from the tools directory of
- the A3000 1.3 Install disk:
-
- Makefiles df0: 1.3 devs:Kickstart1.3
-
- Note that you need to have the 2.0 (or later) fastfilesystem installed on all
- your hard drive partitions when you use 1.3 via the ONETHREE option. Use
- HDToolBox to load the proper fastfilesystem from the l: directory of your
- 2.04 A3000 Install disk (or wherever it may reside on future releases).
-
- VISUAL DIFFERENCES
-
- Whenever you reboot with the Vulcan Neck Pinch (Ctrl-LAmiga-RAmiga), you
- will see a slight difference in screen behavior compared to what you are
- accustomed. You will see two cycles through the black to white screen
- transitions (V37 only. V39 keeps the screen black, so the second trip through
- the ROM is not as obvious). The MMU is turned off on a hardware reset. The
- first set of color changes is the motherboard ROM taking over. SoftBoot magic
- then restores the MMU and jumps to the RAM-based ROM image, causing the second
- trip through the monochrome spectrum. You will get used to it and will use it
- to know when you are RAM-based versus motherboard-based.
-
- DOWNERS
-
- You must obey the following rules concerning RAD: 1) Never, repeat Never
- ever mount RAD: and then try to SoftBoot. Softboot first, then mount RAD:
- (Note the way the DOSDRIVERS drawer is accessed in Kickstart 3.0 really
- helps you run SoftBoot before mounting RAD). Use the KILLROM option to remove
- RAD: before SoftBooting. RAD: works from the top of memory down. SoftBoot
- also wants to put the ROM at the top of memory. As you might guess, neither
- wins when SoftBoot is executed! 2) Always use the BOTH option if you are going
- to use both CPUs and expect RAD: to recover. RAD: seems to work much better
- then because memory allocation is similar between CPU states. If you don't use
- the BOTH option, RAD: will lock up the machine up when switching CPUs. It will
- recover until you make the switch, however. Usually it will either hang
- at the white (Black for V39) screen or continously cycle through the shades
- of grey. You will have to power down to recover.
-
- I tried hard to make this program work on the A2500/030/020. The major
- problem was that the Reset command caused the loss of all chip and fastram and
- the program would lock up. As a result, this version of SoftBoot is very
- A3000 specific. I will be coming out with special versions to support particular
- A2000/040 combinations. Also CBM does not generally make newer beta versions
- of the A2000 operating system available linked at F80000, but rather at 200000.
-
- The ONETHREE option and the Devs:Kickstart1.3 file are specific to the A3000
- and a stock 1.3 kickstart image must not be used in its place.
-
- It must be understood that you have replaced your Alpha superkickstart ROMs with
- some later version, probably V2.04. Softboot requires V2.04 or later ROMS
- in your machine. My A3000 is running custom-made Eproms of a much later verison.
- I suspect that 3.0 ROMs will not give SoftBoot any problems.
-
- VUNERABILITIES
-
- Softboot can be killed in one of several ways. They all require an errant
- program to write over a sensitive area of memory. First, the ROM image itself
- can be corrupted if the transparent translation register is enabled.
- Second, the MMU tables cannot be protected. Third, the Romtag used for
- reboot recovery may get written over. And finally, the ExecBase structure
- could be corrupted.
-
- To help protect the tables (and ROM in 68040 mode), I allocate an extra 256
- bytes around each item, to help prevent the OS (MemList tails) and broken
- programs from overwriting critical data. The ROM is write protected at
- the logical address but is vunerable if the transparent translation
- registers are enabled as the physical address would not be protected;
- the MMU tables are ignored in areas where the transparent translation
- registers are active. SoftBoot has been made as safe as it can be.
-
- ENFORCER
-
- Please use the new Enforcer, V37.26 or later. It is foreign MMU tolerent.
- When it exits, it will return to the previous SoftBoot MMU setup.
-
- HISTORY
-
- Current Version is 3.31
-
- 3.31 - All memory allocations are now checked to see that they are on
- the motherboard RAM. Should any MMU table not be allocated in the proper
- area, the program will print an appropriate message and exit after
- returning all resources back to the old OS with no damage to the old OS.
-
- Reordering of functions allowed the used of _LVOSumKickData() again. The
- in-line code was removed.
-
- 3.30 - The MMU table fill routine was pulled out of main() and made into
- two separate routines: one for 1.3 and one for 2.0+. This allows me to
- change the code so I can delay the final Disable() until just before
- the new OS is launched.
-
- Caches are turned off early in the program. This required additional
- flushing at several points to prevent hanging.
-
- Supervisor() was SetFunction()ed to guarantee it would be available
- after the old ROM was corrupted; SumKickData was in-lined. Now Softboot
- cannot hang because the new OS has different LVOs than the last one or
- depend on certain instructions & data to be in the cache.
-
- The net result is that you can reload any OS on top of another without
- worrying about corruption, or the need to make a special boot disk for
- ONETHREE, for example. You can go directly from 3.0 to 1.3 now no matter
- what the status of the MMU or memory allocation situation.
-
- 3.27 - It was realized that older SoftBoots can now crash because the
- OVRMMU option allows one rom image to be written over the same memory area.
- Previous version worked (sometimes) because LVOs didn't change or the
- instruction cache contained the old rom code, while the data cache
- had (from the copy of) the new ROM image. The first cut at minimizing
- the problems with this was made, in particular, getting the ONETHREE
- option to work with a MMUED OS. It didn't. And led to experimental
- versions 3.28 & 3.29.
-
- 3.26 - Romtag assembled under SAS/C asm V6.00 (Previously used A68K PD
- assembler). Compiler made to use near data and code except for assembly
- functions and data. Romtags Headers made invalid if SoftBoot will not be
- loading a new OS and rebooting. Executable 800 bytes smaller than 3.22.
-
- 3.25 - Same as 3.25 but C code compiled under SAS/C 6.00, previously
- used SAS/C 5.10b.
-
- 3.22 - Another bug found in Zorro III when tested with Progressive ProRAM64:
- Index to 3rd level MMU tables incorrectly generated. Larger of 64K*SlotSize or
- BoardSize is now used to determine span of board. System Memory lists also
- scanned. Should run better on A4000.
-
- 3.21 - Tested on A4000, was intermittant, but OK if run from bootup.
-
- 3.20 - New Z3ALL option added, NOCACHEZ3 option made effective in MMU tables
- and ENTTX mode. Program code for SOFTBOOT parameter removed and ColdReboot()
- used instead. 4K page mode removed. 68040 ROM patch search area increased from
- first 20K to first 50K of ROM. ROM checksum patch search area increased to
- first 10K of ROM. ColdReboot() setfunctioned to restore protected MMU
- setup before system reset to prevent an unprotected ROM from getting
- allocated and corrupted, hanging the machine. ColdReboot() disables
- and dumps all caches (data, instruction, ATC) prior to reset.
-
- 3.14 - Version which had an option to make 4K or 8K page MMU Tables; Added
- the ENTTX option; New ZorroIII MMU table generation algorithm; OVRMMU option
- added. 4K mode known unstable in Softloaded OS, but stable in FASTROM.
-
- 3.0 - Changed patch to Exec to make all 68040 MMU opcode nops rather than
- looking for a specific code sequence and branching around it. This will
- not break again unless the patches are moved away from the beginning of the
- ROM.
-
- 2.50 - Final Cleanup for Beta release to developer community for ADOS 2.0.
- It worked until exec changed in 3.0.
-